I2c fixes #204
I2c fixes #204
Conversation
jlaitine
force-pushed
the
i2c_fixes
branch
2 times, most recently
from
4896164 to
7ef842c
Compare
…g/deinitializing bus Ensure that there are no pending state or interrupts in the i2c controller. This removes errors caused by deinitialize/initialize sequences in error cases. Signed-off-by: Jukka Laitinen <[email protected]>
Add more error status codes to help debugging in the future. Signed-off-by: Jukka Laitinen <[email protected]>
- Use mpfs_i2c_deinit+mpfs_i2c_init sequence to re-initialize i2c block - Use the i2c mutex to protect the reset; in case there are several devices on the same bus, and one of them resets the bus, reset must not occur in the middle of another device's transfer. - Move irq attach to the i2c_init as the irq detach is in i2c_deinit Signed-off-by: Jukka Laitinen <[email protected]>
Add sanity checks for debugging possible errors in the driver. Signed-off-by: Jukka Laitinen <[email protected]>
…s in warm boot Signed-off-by: Jukka Laitinen <[email protected]>
|
I added one more commit to this PR, to recover better from warm reboot |
|
There is still problems reported by testing. Not merging this PR yet, but will continue with measuring the buses after warm reset |
|
Just a desperate idea, try setting SMBus_Reset to 1? (I wonder if disabling the module will stop the clk though) "The I2C protocol specification does not require a specific bus time-out period and typically, the slave device can hold (clock-stretch) the clock line low indefinitely. The SMBus protocol requires a bus time-out of 35 ms, and the PMBus™ protocol requires a bus time-out period of 25 to 35 ms. The purpose of implementing a bus time-out is to prevent stalled devices from indefinitely holding the bus during communication. Although not required by the normal I2C specification, a defined bus time-out may be advantageous as a fail-safe, in events where a stall in communication occurs." CoreI2C: |
|
Verified with oscilloscope that there is no issue with some slave holding the bus. The following is observed: If the device is reset in the middle of read sequence, before the interrupt is cleared, after the warm boot it is not possbile to get any more interrupts from that i2c block. It is possible to poll the irq status and write to the bus properly, but there are just no irqs -> hence the bus gets stuck at every "start" condition... I'd say that these fixes are good to go, and more investigation is needed for the remaining issue. |
|
Merging this-> |
Summary
This fixes some issues with initializing, re-initializing and resetting mpfs i2c + adds some debug capabilities for the future use if ever needed
Impact
Fixes the issue where a failing magnetometer (wire getting loose) knocks out cold the whole bus, including voltage measurements, lidar lite and barometers.
Testing
On-desk tested with saluki-v2 with core-i2c